Figure 1.2a shows the timeline for the project in which all of these plans will take place. Creating and designing the Prototype is the main goal of the first semester.

Figure 1.2b on the next page shows the basic plan for the second semester. We will divide the implementation of the system into three phases:

4Phase 1: We will complete all necessary functionality for playing a Hotseat game. This includes finishing and tidying up the interface, enforcing wall and token constraints (i.e. – Can’t place a wall on top of an existing wall), and allowing up to four players.

4Phase 2: We will add networking capabilities to our existing implementation. This will allow for several combinations of users to play over a network.

4Phase 3: AI functionality will be added. This includes inserting AI module into the program in a user-friendly environment to allow an AI to play the game.

Figure 1.2a - CS 425 Timeline

Phase 1

(Hotseat)

Phase 2

(Networking)

Phase 3

(AI)

Figure 1.2b - CS 499 Timeline (Green = Aaron, Blue = Chris, Red = Mark, Purple = Matt, Orange = Todd, Black = All members)

1.3) Stakeholders

The members of Team Quoridor are the primary stakeholder, since the success of this project will be a key factor in the team’s progress in the Senior Project course. AI students will be another stakeholder, since this program would be helpful in aiding their education in programming AI modules. Professor Klein will also be a stakeholder in this project. He is the client, so he is dependent on Team Quoridor to successfully deliver a successful project.

1.4) Design Decisions

All aspects of design specific to the project can be found in the Quoridor Design Document. This includes such aspects as subsystem decomposition, hardware and software mapping, and user interface design.

2.) Human Organization Plan

In this section, we explain the roles of each team member. The organizational hierarchy explained in this section is represented in Figure 2.

Aaron O’Banion is the Project Manager and is responsible for organizing most aspects of the project. All questions and concerns will be forwarded to the group. In case of a stalemate, Aaron will make the final decisions for the project. Steven Klein is the main client contact. We will contact Mr. Klein if we would like to meet with the clients or if we have a question or suggestion. Upper Management may also be contacted for questions regarding the project.

It should be noted that for each aspect and role in the project, no one person will do all of one thing. This way, each person is exposed to multiple aspects of the project.

Todd Astroth is the Lead Documenter. He is responsible for the basic writing and organization of all documentation during the project (see Section 6 of this document). Other team members will contribute to documentation by thoroughly proofreading and editing each document.

Mark Williams is Lead Designer and is in charge of the Design phase of the project. The Lead Designer will communicate with other team members to analyze what is needed in the system.

Matt Stowe is Lead Programmer is responsible for assigning programming assignments to other team members. Matt will ensure that the project design is being followed and that the requirements for the project are being met with the programming that is done.

Chris Cobb is the Lead Tester and will be responsible for coordinating the testing of the system. See Section 4 of this document for more information on how we will do the necessary testing for the project.

Figure 2 - Basic Organization Chart

3.) Risk Management

The table below in Figure 3 summarizes the risks we have foreseen thus far and how to deal with the risk should it occur.

Risk	Description	Solution
Team Conflicts	Conflicts could arise between team members about the project or personal matters. This would slow the development process.	Private discussion with team leader or Upper Management.
Backtracking Difficulty	Upon development of certain features, such as the networking and AI issues, we may have to backtrack through design.	Team will redevelop design and proceed from there.
Team Member Lost	A team member may need to leave the team due to reasons beyond the team’s control. This would increase the work load for the remaining members.	The unfinished work will be redistributed amongst remaining team members.
Acceptance Issues	During review, our client Mr. Klein may inform us that an aspect of the system contradicts the view of his expected criteria.	We would refer back to the contract to clear up confusion. If there is an error on our part, we will fix the issue.
Late Finish	The project could drag out as a result of additional functionality becoming more complicated than expected.	Additional features will be left out and the basic system would still be functional.
Feature Creep	Adding extra features to the program could delay the development of more important functionality.	Save optional functionality for the very end and implement if time allows.
Networking Difficulties	Lack of knowledge of networking in VB could cause unforeseen difficulties in implementing the network.	We’ll spend time learning the networking before Phase 2 and set extra time and resources.
AI Functionality	Lack of knowledge of AI could cause unforeseen difficulties in coding the AI modules, and the AI functionality depends on the networking functionality.	We’ll spend time learning about AI’s before Phase 3 and set extra time and resources.

Figure 3 - Risks in the Quoridor Project

4.) System Testing Plan

In this section, we traverse through the different types of testing we will use during the project. For all testing, we will use Visual Basic’s compiler and debugger to locate bugs and track the progress of the program.

4.1) Module Test (Interface subsystem)

4.1.1 Objective

We will test our Interface subsystem to ensure all visuals and graphics behave according to the requirements stated in the Requirements Analysis Document. We want to make sure the interface will allow us to perform the minimum functionality before we constrain the game with the rules of Quoridor (see Section 4.2).

4.1.2 Procedure

We will design scripts to test the various graphical user interface functions. These functions include placing walls on the game board, moving tokens across the board, changing a player’s turn by indication on the right side of the board, setting the board size, setting the number of players, taking players to the board after setup, etc..

A script consists of a list of step by step commands to be issued to the interface by a user. A different script will have to be developed to test gameplay on 3 different board sizes (the minimal 6x6, the default 10x10, and the max 12x12 boards). An example of a script would consist of both players moving their pieces to every square as well as players placing walls at specific spots. Illegal move validation is not incorporated at this module test, so this will not be tested nor performed in the script.

4.1.3 Example

Sample script testing to see if tokens will move across the board, space by space from the starting zone to the goal zone (assuming space highlighting and player turns are already implemented). This script tests if a player can move his or her token across the board, if a player can achieve a victory, and if a wall can be placed.

· Set the board to 6x6 board (one of the 3 sizes to be tested. This script tests this board size).

· Number of walls will be set to 3 per player in the set-up screen.

· Player 1 and Player 2 will be set to human, 3 and 4 will not be active.

· Begin the game by clicking “Start.”

· Move player 1’s token from the start bar to the 3^rd square from the left at the bottom of the board.

· Move player 2’s token from the start bar to the 4^th square from the left at the top of the board.

· Move player 1’s token one square up.

· Move player 2’s token one square down.

· Place a wall on the far right of the board.

· Move player 2’s token one square down.

· Repeat moving across the board for both players, until player 2 makes it to the edge of the board.

· Drag player 2’s token off the board.

4.2) Module Test (Interface subsystem with game validation)

4.2.1 Objective

We will test our Interface subsystem to ensure all visuals and graphics behave according to the requirements stated in the Requirements Analysis Document. We want to make sure the interface will allow us to perform the functionality of validation consistent with the rules of Quoridor.

4.2.2 Procedure

We will design scripts to test the various graphical user interface functions as well as ensuring that the illegal move checkers work correctly. These functions include placing walls on the game board, moving tokens across the board, changing a player’s turn by indication on the right side of the board, setting the board size, setting the number of players, taking players to the board after setup, and stopping players from performing illegal moves.

4.2.3 Example

· Set the board to 6x6 board (one of the 3 sizes to be tested. This script tests this board size).

· Number of walls will be set to 1 per player in the set-up screen.

· Player 1 and Player 2 will be set to human, 3 and 4 will not be active.

· Begin the game by clicking start.

· Move player 1’s token from the start bar to the 3^rd square from the left at the bottom of the board.

· Move player 2’s token from the start bar to the 4^th square from the left at the top of the board.

· Move player 1’s token one square up.

· Move player 2’s token one square down.

· Place a wall on the far right of the board.

· Place a wall on top of the previously placed wall (should be rejected).

· Place a wall so that the top of the wall overlaps with the previously placed wall’s bottom. (Should be rejected).

· Place a wall so that the bottom of the wall overlaps with the previously placed wall’s top (should be rejected).

· Move player 2’s token one square down (after all the rejections it should still be player 2’s turn).

· Move player 1’s token one square up.

· Move player 2’s token one square left. Should be rejected (Player 1 is in that location).

· Move player 2’s token one square down.

· Repeat moving across the board for both players, until player 2 makes it to the edge of the board.

· Drag player 2’s token off the board. He should be declared the winner.

4.3) Integration Tests (For each Phase)

4.3.1 Objective

Our system will be divided into three phases. In the first phase, we will test the Interface subsystem with all game validation functions. In the second phase, we add all functionality dealing with networking to the existing system tested in Phase 1. In Phase 3, we take the existing tested system from Phase 2 and integrate AI functionality.

4.3.2 Procedure

Modules will be grouped together for each phase. Once again, we will use scripts to test the various functionality added to each phase. For Phase 2, a human player should be able to play against an opponent human on another computer. In Phase 3, a user should be able to insert an AI into the game. In both Phases, the game should be fully functional for the given players.

4.3.3 Example

For the Interface plus Game Validation functionality (Phase 2), sample script testing to see if a very simple game of Quoridor can be played over a network.

· Start a game with a 6x6 board, 2 walls per player, and 2 player, one local and one remote (human).

· Player 1 moves his/her token to the third square from the left of the bottom row.

· Player 2 moves his/her token to the forth square from the left of the bottom row.

· Player 1 places a horizontal wall at the far left side of the board in the upper right corner.

· Player 2 places a horizontal wall at the same location (should be disallowed).

· Player 2 places a horizontal wall below the previous wall.

· Players 1 and 2 will continue to march down the board. Player 1 should make it to his/her goal first.

· Player 1 will move off the board. He should be declared the winner, and player 2 should not be allowed to move.

4.4) System Test

4.4.1 Objective

The system will be tested as a whole in an environment similar to that of the client’s.

4.4.2 Procedure

The only major difference between the System test and the Integration test for Phase 3 is that we will test the system by playing the game as an executable. All programming aspects will be “hidden” to ensure the user is separate from the implementation. We will combine functionality from scripts from previous tests to fully test the game. Emphasis will be on testing the requirements set by the client.

4.4.3 Example

In this example script, we are playing a game over a network using AI’s:

· Start the Quoridor program.

· Set Board size to 10x10.

· Set the wall limit to the maximum allowed.

· Player 2 is an AI. Set this up using the given AI file.

· Start the game.

· Each player (including the AI) should attempt to place walls until no more can be placed (The game should indicate that there are no more valid positions to play a wall).

· Each player should move their tokens to their goal zone, space by space, by moving forward if possible (The game will prevent going forward if there is a wall in the way). Otherwise, move left or right.

· When the first player reaches their goal, a message should appear saying they have won.

4.5) Acceptance Test

4.5.1 Objective

The system should meet all requirements of the client.

4.5.2 Procedure

The system will be tested at the client’s site using all functionality that he requested from the contract, which would be our client’s office computer. We will use the same scripts from the system test.

4.5.3 Example

See example for System Test (section 4.4.3)

5.) Alterations to the System

This section explains how Team Quoridor will deal with changes to the system during the project.

5.1) Baselines

5.1.1 Problem Specification

This is defined in the Requirements Analysis Document.

5.1.2 Design Specification

This is defined in the System Design Document.

5.2) Proposing a Change

5.2.1 Who May Propose a Change

(a) Team Members:

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and Todd Astroth.

(b) Clients and Other Personnel:

Steve Klein, Bernard Waxman, Stephen Blythe, Daniel Dooly

5.3) Investigating a Proposed Change

5.3.1 Who, How, When

All team members will be in charge of investigating a proposed

change. Any major changes to the project structure will result in a version update of any documents involved.

5.3.2 Investigation Report

The team will analyze the change during meeting hours and design solutions to the change. Any discovered major changes will be updated in the applicable documents (RAD or SDD).

5.4) Change Management Board

5.4.1 Membership

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, Todd Astroth

5.4.2 When it Meets

The change management board will meet during the group’s regular meeting hours: 12:30pm to 1:45pm Tuesday and Thursday in Engineering Building 1010; or extended hours: 6pm to 9pm Monday and Wednesday in Dunham Hall 2009.

5.5) Implementing a Change

5.5.1 Approvals Needed

(a) Project Team:

The project team needs to form a general consensus among members. In the end, the Team Leader will make the final decisions.

(b) Client:

The client does not have to approve a change before it can be implemented, unless the change is considered to be outside the boundaries of the client’s scope.

5.5.2 Documenting the Change

Major changes will be updated in the applicable documents affected: namely, the RAD and SDD.

5.5.3 Scheduling the Change

The project will be rescheduled in the event that a major change has been implemented.

6.) Required Documentation

This section maps out our plan for documentation involved in the project. Each major document will adhere to the guidelines set in this section. Major documents include:

§ Requirements Analysis Document

§ System Design Document

§ This Project Plan Document

§ Weekly progress logs (for each team member)

§ User Manual

§ Help Menu (in program)

6.1) Publication Procedures and Responsibilities

6.1.1 Preparation and Approval

Documents other than logs will be reviewed by Team Quoridor. If future changes are necessary to these documents, the changes will be executed through the Alteration Plan (see Section 6). The Project Manager will make the final decision on the posting of version updates.

6.1.2 Typing

Each document will mainly be written and compiled by the Lead Documenter. Other the team members can contribute to typing as well. Once each section is completed, the document will be ready for proofreading and editing.

6.1.3 Proofing and Editing

Documents other than the logs will be proofread by the team during regular team meetings. Once the entire document is proofread, the Lead Documenter will edit the document based on the requests of team members.

6.1.4 Distribution

The client may request any documentation at any time. All versions of the documentation will be kept with the Lead Documenter.

6.1.5 Electronic Storage

All documents will be available via the project website at: www.cs.siue.edu/SeniorProjects/2005/fall/QuoridorTeam/

6.2) Project Document Template

6.2.1 Title Page

All project documents other than logs will have a title page that contains the following: the name of the document, the Quoridor logo, the authors of the document, and the version of the document.

6.2.2 Numbering

All documents other than logs will be numbered numerically with subsections indicated with decimals. After two decimals, sections will be alphabetically labeled.

7.) Human Training Plan

This section provides what training will be needed for both internal and external sources. Internal sources include members of Team Quoridor, and external sources include the client and other spectators.

7.1) Internal Training

7.1.1 Coding Languages

Team members have used Visual Basic before, team members will need to recall their Visual Basic skills. Also, members need to learn how to use socket programming for manipulating networks.

7.1.2 Interfacing With Other Subsystems

Team members will need to understand how to link subsystems together over a network in order for the system to function as a whole. We have decided that we will learn and implement socket programming in Visual Basic.

7.1.3 AI Modules

Team members are responsible for understanding how to implement basic Artificial Intelligence modules so that we can add this functionality to the system later. We should also be able to make this functionality as easy to use for our client and intended audience.

7.2) External Training

7.2.1 Installing the Software

The team will install the finished Quoridor project on the computer(s) of the client’s choice. The team will train the client if the situation is deemed necessary.

7.2.2 Using the System

Once again, the team may provide help to the client with the system if it is needed. We will provide a User Manual and a Help Menu for the system to help answer most user questions.

8.) Review and Reporting Plan

This section explains how we will review and report the group’s progress during the Senior Project. Reviews and reports are generally formed on a regular basis. Written content can be found on our website. More information about written documentation can be found in Section 6.

8.1) Reviews

8.1.1 Documents

The team will create three major documents – namely the Requirements Analysis, Software Design, and Project Plan documents. These will be submitted to Upper Management to review.

8.1.2 PowerPoint Presentations

The team will create presentations to review what we have done so far. These presentations will take place at regular intervals during both semesters. The audience will mainly include other team members and Upper Management.

8.1.3 Client Acceptance

The team will contact the client when a major milestone has been completed or when a major question or concern has come up.

8.1.4 Upper Management Acceptance

In addition to reviewing the documentation, Upper Management will provide verbal feedback about the status of the project and the team.

8.2) Reports

8.2.1 Individual Weekly Team Member Logs

Each team member will report what he does with regards to the project each week. These will be compiled and checked for consistency each week. These logs will be checked by Upper Management to assess Team Quoridor.

8.2.2 Meeting Notes

On occasion, the Lead Documenter will compile a list of important notes based on discussions from group meetings. These notes will generally be in a Word document.

9.) Installation and Operation Plan

9.1) Installation

9.1.1 Responsibility

The development team – namely Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and Todd Astroth – will install the system at the client’s site.

9.1.2 Schedule

The installation of the system will occur on or before April 25, 2006.

9.1.3 Multiple-Site Considerations

Team Quoridor will be responsible for the installation of the system

at the client’s site only. The system may be distributed from that point forward as the client wishes.

9.2) Operation

9.2.1 Responsibility for Operation

The client will be responsible for all aspects of operating the software after it has been installed by the team.

9.2.2 Responsibility for Maintenance and Tuning

No maintenance or tuning will be provided for.

9.2.3 Duration of Responsibilities

The Quoridor team will be responsible for the software product until the client accepts the final product or until the end of the Spring semester 2006.

10.) Hardware and Software Requirements

Expected hardware for the project will include a PC with the appropriate specifications to run a current version of Windows XP. Microsoft Visual Studio will be used for programming and designing our application. We will need access to a computer network for designing games between multiple computers.

11.) Contributions

Project Plan Version 1.0:

Todd Astroth – Rewrote and edited (all sections) of Project Plan Document, rewrote problem areas indicated by Dr. Waxman (mainly Testing Plan and Timeline)

Aaron O’Banion – Wrote basic outline of PPD, proofreading and editing of Project Plan Document

Chris Cobb – Designed the plan for the project, proofreading and editing of Project Plan Document, designed test cases

Matt Stowe – Designed the plan for the project, extensive proofreading and editing of Project Plan Document

Mark Williams – Designed the plan for the project, extensive proofreading and editing of Project Plan Document

Project Plan Version 2.0:

Todd Astroth – rewrote problem areas indicated by Dr. Waxman (mainly Testing Plan and Timeline)

Chris Cobb – proofread and edited version revision by Todd, re-rewriting of Testing Plan

Project Plan Version 3.0:

Todd Astroth – updated contents that have changed since the first semester. Created an HTML version for viewing online.

Project Plan Presentation:

All team members are responsible for designing and presenting their respective speaking sections of the presentation.

Project Plan Poster:

Chris Cobb

Website:

Chris Cobb